This is a tracking bug for the failure of detouring ntdll!NtMapViewOfSection. In most of the instances, the platform is Win7.

The priority flag is not set for this bug.
:aklotz, could you have a look please?

For more information, please visit auto_nag documentation.

Many instances of the launcher failure ping indicate hooking NtMapViewOfSection
or LdrLoadDll failed. This is most likely caused by a third-party application
applying a hook onto the same target earlier than we do.

This patch is to add a new field "detour_orig_bytes" in the laucnher failure ping
to collect the first sixteen bytes of a detour target function. With this,
we can know whether those detour failures were caused by a third-party hook or not,
and if yes, what was the actual binary pattern.

Comment on attachment 9175059 [details]
data-review-request-for-bug1588245txt

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes.

Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.

If the request is for permanent data collection, is there someone who will monitor the data over time?

Toshi is responsible for the collection for its lifetime.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 1, Technical.

Is the data collection request for default-on or default-off?

Default on for pre-release channels only.

Does the instrumentation include the addition of any new identifiers?

No.

Is the data collection covered by the existing Firefox privacy notice?

Yes.

Does there need to be a check-in in the future to determine whether to renew the data?

No. This collection is permanent.

Result: datareview+

Backed out changeset d5725a81ffd7 (bug 1588245) for Windows build bustages. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=315879384&repo=autoland&lineNumber=8700

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=315879420&repo=autoland&lineNumber=8646

Push that introduced failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=d5725a81ffd705951bf7889f4247963c8edc3943

Backout:
https://hg.mozilla.org/integration/autoland/rev/169dd2c2a81200d367103e8e8fdc2c2b42c91da6

https://hg.mozilla.org/mozilla-central/rev/d8315e4ed18d

The previous commit d8315e4ed18d introduced a new telemetry field
in the launcher process ping to collect the assembly pattern of
a target function on detour failure, but most of the crash instances
do not have a value in the field. This means the failure happens
before or after CreateTrampoline.

To narrow down the root cause, this patch puts a fine-grained error value
in the "hresult" field instead of the hardcoded ERROR_UNIDENTIFIED_ERROR.

This patch also adds IsPageAccessible check before fetching data from
a different process because fetching data from an invalid address hits
MOZ_RELEASE_ASSERT in EnsureLimit, resulting in crash without sending
the launcher process failure.

https://hg.mozilla.org/mozilla-central/rev/1b81ea85c43d

This is the third attempt to investigate the launcher failure of our detour.
The previous commits d8315e4ed18d and 1b81ea85c43d added the assembly bytes
of a detour target and a special error code DetourResultCode to the launcher
failure ping.

In the latest telemetry data, however, the most common value of hresult
is still ERROR_UNIDENTIFIED_ERROR, meaning the previous commit missed to
set an error code in the common fallible codepath we wanted to know.
Besides ERROR_UNIDENTIFIED_ERROR, we're seeing DETOUR_PATCHER_DO_RESERVE_ERROR
in the telemetry, but having that code is not enough to pinpoint a falling
operation.

For further investigation, this patch adds ten more values to DetourResultCode.
FUNCHOOKCROSSPROCESS_COPYSTUB_ERROR is the last codepath we forgot to cover
in the previous commit. The values of MMPOLICY_RESERVE_* are to investigate
DETOUR_PATCHER_DO_RESERVE_ERROR in the MMPolicy level. In both cases, we add
the last Windows error code to DetourError::mOrigBytes.

https://hg.mozilla.org/mozilla-central/rev/0a114b5e07eb

Backed out on suspicion of crashing Firefox on startup (bug 1670546 etc.)

Backout: https://hg.mozilla.org/mozilla-central/rev/36e9dba4b99c2a5dc1d8456439f2e239ca0571b7

https://hg.mozilla.org/mozilla-central/rev/4b1e25bb322d

The latest telemetry shows no failure from detouring NtMapViewOfSection. Resolving this as Fixed.